在導入 dbt 之前的世界

2022 年，當時的公司主要透過：

• Google BigQuery 儲存 SQL-based 的 stored-procedure（運算資料的任務本身）
  • 功能：每一個 DDL（創建表格） / DML（插入資料）的行為，都被儲存為一個 stored-procedure
  • 範例：生產捐款者在平台的使用行為，並將顆粒度調整為縣市層級
    • table_a: doner's metadata
    • table_b: user's activity log
    • procedure_doner_activity_report: create a table_c as (table_a join table_b using user_id, then group by city)
• Apache Airflow 定時觸發 stored-procedure（規劃執行該任務的時程）
  • 功能：每一隻 stored-procedure，都會被 airflow dag 安排 dependency，並定期執行
  • 範例：清理資料 -> join table -> 生產報告
    • step 01: delete failed donation in table_a
    • step 02: delete duplicated activity log in table_b
    • step 03: trigger procedure_doner_activity_report.sql

（阿華炒麵的例子，待補XD）

這有什麼問題？

我們大概可以發現，這套系統無須人力介入，Airflow 負責處理 shcedule & dependency，BigQuery 負責處理 sql code & computing data。然而，每當服務需要升級的時候，效果都不盡理想。問題包括：

1. 關係複雜：資料架構龐大時，難以清楚看見上下游關係。（雖然：計畫設定好了之後，airflow 能較好的按計畫執行）
2. 耦合問題：當多個模組重複使用、仰賴同一組 .sql 時，必須仰賴良好的文件管理，de-sync 之後都會很難追查（雖然：文件管理只要隨時保持在最新的狀態，就可以解決這些問題）
3. 資料品質：在 Airflow 可以透過 great expectation / test 來管理資料品質，但入門的門檻極高。（雖然：只要寫好 test，仍然能做一些資料檢查）

而這些問題，正好可以透過 dbt 來整合！